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(54) Vehicle sharing system and method with parking state detection 



(57) A shared vehicle system includes a central fa- 
cility 12, at least one vehicle distribution port facility 14 
and a plurality or fleet of vehicles 16, each having a ve- 
hicle subsystem 18. In general, the central facility 12 and 
port facility 14 and the vehicle subsystems 18 commu- 
nicate in a manner to allow a user to enter information 
at a port facility 14. That information is then communi- 
cated to the central facility 12, where the information is 
processed to select a vehicle 1 6 from the fleet to allocate 
to the user 20 at the port facility 1 4. Selection of a vehicle 
16 for allocation to a user 20 may be based on selecting 
an available or soon to be available vehicle according 



to various algorithms that take into account the vehicles 
state of charge. The central station 12 also communi- 
cates with the port facility 1 4 and the vehicle subsystem 
18 to notify the user 20 of the selected vehicle 16, to 
provide secure user access to the selected vehicle 16, 
to monitor the location and operating status of vehicles 
in the fleet, to monitor the state of charge of electric ve- 
hicles and to provide other functions. The vehicles com- 
municate with the central station to notify the central sta- 
tion of the PIN number of the individual 20 attempting to 
use the vehicle, and of vehicle parameters such as state 
of charge and location of the vehicle 
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Description 

BACKGROUND OF THE INVENTION 
Field of the Invention : 

[0001] The present invention relates, generally, to 
systems and methods for sharing a fleet of vehicles 
among a plurality of users and, in preferred embodi- 
ments, to such systems and methods for sharing a fleet 
of electric vehicles, including systems and methods re- 
lating to allocating, tracking, securing, managing and re- 
locating of shared vehicles and, in yet further preferred 
embodiments, to systems and methods relating to allo- 
cating, tracking, securing, managing, relocating and 
charging of shared electric vehicles. 

Description of the Related Art : 

[0002] In most modem, industrial countries, private 
automobiles play an important and sometimes indispen- 
sable role as a means for transporting people within and 
beyond local areas, for example, to and from places of 
work, study or worship, on errand trips or in commercial 
activities, such as deliveries, sales visits, repair visits or 
the like. As a result of these important roles, the number 
of automobiles in and around most industrialized cities 
and neighboring regions continues to grow. The increas- 
ing numbers of automobiles results in higher occurrenc- 
es of traffic jams and higher demands for parking spac- 
es. 

[0003] Mass transit systems, such as busses, com- 
muter trains, subways, streetcars or the like can fulfill 
some of the transportation needs of those communities 
and municipalities that have such systems. However, 
travel with such systems is confined to pre-set stop lo- 
cations and times, set by the route and time schedule 
of the bus, train, subway or streetcar. The prescribed 
routes and time schedules typically do not meet many 
travelers' needs or are too inconvenient for practical us- 
age of the mass transportation system by some travel- 
ers. For many mass transportation users, the pre-set 
stop location is far enough from their origination or des- 
tination locations that they must find additional modes 
of transportation to or from the pre-set stop. For exam- 
ple, some users drive private vehicles to and from pre- 
set stop locations and park the vehicles near the stop 
locations. Some mass transportation systems even pro- 
vide vehicle parking facilities near pre-set stop locations 
for such users. 

[0004] For example, commuter train stops and bus 
stops in and near some cites are often provided with 
parking lots for train users to park private vehicles. How- 
ever, vehicles in such parking lots typically remain 
parked throughout a large part of the day, and are driven 
only in the morning to bring the user to the train or bus 
stop and in the evening to take from the train or bus stop. 
Thus, while modem mass transportation systems can 



result in a reduced number of vehicles on the road at 
any given time, such mass transportation systems do 
not eliminate the need for private vehicles and can result 
in an inefficient use of private vehicles. 
s [0005] Accordingly, there is a need for a system and 
method for the efficient and convenient use of private 
vehicles, such as an efficient and convenient shared ve- 
hicle system and method. Shared vehicle systems can 
provide more flexibility than other means of public trans- 
10 portation. In a shared vehicle system, a number of ve- 
hicles are normally maintained in several designated 
parking areas. Each user is allowed to pick up a vehicle 
at one parking area, and return the vehicle to the parking 
area nearest to the user's destination. The user may al- 
so drive a vehicle out of a designated parking area for 
an errand and return the vehicle to the same designated 
parking area Shared vehicle systems that are used by 
a relatively large number of subscribers should include 
sufficient security measures to protect the vehicles from 
theft and also to protect the user from crime. 
[0006] Shared vehicle systems must be sufficiently 
convenient to motivate users to employ the system. Ac- 
cordingly, vehicle availability within a reasonable time of 
a user's request for a vehicle is very important to the 
success of such a system. Of course, by maintaining a 
greater number of vehicles in the fleet of shared vehi- 
cles, the availability of a vehicle at any given time can 
be increased. However, system cost is minimized and 
vehicle-usage efficiency is maximized with smaller ve- 
hicle fleets. Accordingly, there is a need for a shared 
vehicle system that maximizes user convenience yet 
minimizes the number of vehicles required in the fleet. 
[0007] In particular, by employing vehicles in a shared 
vehicle system or method, additional ecological advan- 
tages can be achieved. Vehicles in a shared system may 
be of many types. They may be the conventional petro- 
leum based gasoline or diesel fuel type vehicles. They 
may however be cleaner forms of propulsion such as 
methanol or propane powered vehicles, or may be ve- 
hicles powered by hydrogen stored as a gas or metal 
hydride. Electric vehicles may draw energy from batter- 
ies, fuel cells, generators driven by internal combustion 
engines, or combinations of different energy sources. 
Electric vehicles powered by both lead acid and nickel 
metal hydride batteries have shown much promise and 
several manufacturers have produced viable electric ve- 
hicles employing these battery technologies. Electric 
vehicles are a good candidate for a shared vehicle, be- 
cause they are among the cleanest and quietest forms 
of vehicle, but sharing systems and methods are in no 
way dependent on the use of an electric vehicle, and 
may be employed with a number of non electrical or hy- 
brid technologies, including common gasoline power. 
[0008] The use of electric powered vehicles in a fleet 
of shared vehicles, however, presents further complex- 
ities over other alternate power vehicles, for example, 
associated with vehicle charging requirements and ve- 
hicle unavailability during charging times. 
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[0009] Electric vehicles typically require charging 
more often than the conventional vehicles require refu- 
eling. Recharging stations are not nearly as available as 
conventional petroleum motor fuels. Moreover, recharg- 
ing of an electric vehicle typically takes much more time 
than refueling a conventional vehicle. Thus, if a conven- 
tional vehicle is present at a designated parking area of 
a shared vehicle system, but does not have sufficient 
fuel to meet a user's travel needs, the vehicle can be 
quickly refueled and made available to the user. How- 
ever, even when an electric vehicle is idle in a designat- 
ed parking space, it is not available to a user unless it 
has a sufficient existing state of charge (SOC) to make 
the user's intended trip. Typical ly, an electric vehicle 
cannot be re-charged quickly enough to make the in^ 
tended trip if its existing SOC is inadequate. On the other 
hand, rf the user intends to make a short trip, the vehicle 
may be capable of making the intended trip even though 
it is not fully charged. Accordingly, there is a further need 
for a system and method for managing shared electric 
vehicles in an optimum fashion and to meet the needs 
of a maximum number of users with a minimum number 
of vehicles. 

SUMMARY OF THE DISCLOSURE 

[0010] Therefore, preferred embodiments of the 
present invention relate to shared vehicle systems and 
methods that maximize user convenience and minimize 
the number of vehicles required in the shared fleet. 
[001 1 ] A shared vehicle system according to one pre- 
ferred embodiment of the present invention includes a 
central facility, at least one vehicle distribution port fa- 
cility and a plurality or fleet of vehicles, each having a 
vehicle subsystem. In general, the central station and 
port facility and the vehicle subsystems communicate in 
a manner to allow a user to enter information at a port 
facility. That information is then communicated to the 
centra] facility, where the information is processed to se- 
lect a vehicle from the fleet for allocation to the user at 
the port facility. The central station communicates with 
the port facility and the vehicle subsystem, according to 
various embodiments described below, to notify the user 
of the selected vehicle, to provide secure user access 
to the selected vehicle, to monitor the location and op- 
erating status of vehicles in the fleet, to monitor the state 
of charge of electric vehicles and to provide other func- 
tions described below. 

[0012] According to one aspect of the invention, allo- 
cation of shared vehicles to users is based, at least in 
part, on travel information received from the users. By 
allocating vehicles based on travel information the effi- 
cient usage of vehicles and user convenience can be 
optimized, for example, to maximize vehicle availability 
and minimize vehicle downtime. While various embod- 
iments related to this aspect of the invention may em- 
ploy any form of shared vehicle, according to further em- 
bodiments of the present invention, vehicle sharing sys- 



tems and methods employing electric vehicles in the 
shared fleet and the allocation of electric vehicles to us- 
ers is managed to maximize vehicle availability and min- 
imize vehicle downtime, taking into account the state of 
5 charge of a vehicle and/or the charging rate of a vehicle. 
[0013] According to another aspect of the invention, 
a shared vehicle system or method provides controlled 
or secured access to and/or enablement of the shared 
vehicles. In preferred embodiments, user identification 
10 information is provided to a vehicle that has been allo- 
cated to a user and such information must match infor- 
mation entered by the user in a user interface device 
installed on the vehicle, before the user is allowed ac- 
cess to the vehicle. In yet further preferred embodi- 
es ments, a user's personal identification number PIN must 
be entered by the user in a second interface device in- 
stalled on the vehicle and must match an expected PIN, 
before the vehicle is enabled for operation. 
[0014] According to yet another aspect of the inven- 
20 tion, a shared vehicle system and method involves allo- 
cating vehicles from a group of available vehicles and 
returning vehicles to the group upon detection of a park- 
ing state while the vehicle is located at a port. A port is 
a vehicle staging area where vehicles may be parked 
25 prior to being allocated to a user. A typical port contains 
a user kiosk containing a computer terminal for interact- 
ing with the shared vehicle system. Throught this dis- 
closure the term "kiosk" will be used to mean a kiosk 
with a user terminal. The terms kiosk and terminal shall 
30 be used interchangeably herein. In preferred embodi- 
ments, the detection of a parking state is accomplished 
by, for example, the detection of the setting of the vehicle 
in a parking gear, the lack of motion of a vehicle for a 
period of time, the opening and/or closing of a vehicle 
35 door, or a combination of such events, each of which 
require no user interaction other than the typical actions 
taken to park a vehicle. 

[0015] According to yet another aspect of the inven- 
tion, a shared vehicle system and method involves pro- 

40 tecting access and enabling vehicles from a remote lo- 
cation relative to the vehicles, for example, in the event 
that a user loses an identification code or PIN. 
[0016] According to yet another aspect of the inven- 
tion, a shared vehicle system and method involves 

45 tracking stored energy and/or other operational param- 
eters of vehicles in the shared fleet In preferred embod- 
iments, vehicle parameters, such as stored energy, are 
tracked and processed for purposes of efficient selec- 
tion and allocation of vehicles to users or selection of 

50 vehicles for charging. 

[0017] According to yet another aspect of the inven- 
tion is that, if electrical vehicles are employed within a 
shared vehicle system, the electrical vehicles are allo- 
cated to users based on the state of charge (SOC) of 

55 the vehicles, in addition to vehicle location, user travel 
information and statistical analysis of vehicle usage. Ac- 
cording to a further advantage of preferred embodi- 
ments, vehicles are allocated from a defined vehicle 
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search group (VSG) of a port facility. A vehicle search 
group is defined as the set of vehicles that may be allo- 
cated to a user. A vehicje search group is determined 
by deciding what time period is acceptable as a vehicle 
search depth time, that is how long a predefined wait is s. 
acceptable before a vehicle becomes available. The ve- 
hicle search group then is ascertained by determining 
which vehicles will be available at the end of the prede- 
fined waiting period. Vehicles within the vehicle search 
group of a port facility include vehicles that are due to 10 
arrive at the port facility within the predefined period of 
time or electric vehicles that are due to become suffi- 
ciently charged at the port facility within a predefined 
period of time, minus the vehicles within the port that 
have been allocated for departing trips or are scheduled *5 
for transport to another port facility. 
[0018] In one preferred embodiment that includes 
electrical vehicles within the shared vehicle group, a us- 
er is allocated a vehicle having the highest SOC within 
a vehicle search group of vehicles having sufficient SOC 20 
to meet a user's needs. In another preferred embodi- 
ment, a user is allocated a vehicle having the second 
highest (or Nth highest) SOC within a vehicle search 
group of vehicles having sufficient SOC to meet the us- 
er's needs, such that the highest (or N-1 highest) SOC 25 
vehicles may be reserved for users having travel needs 
which requiring a higher SOCs. In yet another preferred 
embodiment, the system or method has the ability to al- 
locate the highest or Nth highest SOC vehicle, depend- 
ing upon other criteria, such as the time of day or day of so 
the week. Thus, for a certain time period of the day and/ 
or day of the week (for example, between 7:00 a.m. and 
9:00 a.m. on Monday through Friday) the system or 
method may allocate the highest SOC vehicle in the ve- 
hicle search group is allocated to a user, while at other 35 
times of the day and/or days of the week, the Nth highest 
SOC vehicle is allocated to a user. 
[001 9] According to a further aspect of the present in- 
vention, a shared vehicle system and method involves 
transporting or relocating vehicles from one area or port 40 
having a surplus of vehicles to another area or port hav- 
ing a shortage of vehicles. Vehicles may also be trans- 
ported to effectively use storage space for the parking 
of the vehicles. According to yet a further aspect of the 
present invention, a shared vehicle system and method 45 
involves a vehicle carrier for carrying a first vehicle with 
a second vehicle, for example, for relocating the first 
and/or second vehicle. 

[0020] The above and other aspects, features, and 
advantages of the present invention, will become appar- so 
ent from the following description when taken in con- 
junction with the accompanying drawings in which pre- 
ferred embodiments of the present invention are shown 
by way of illustrative example. 

55 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0021 ] Referring now to the drawings in which like ref- 



erence numbers represent corresponding parts 
throughout: - 

Fig. 1 is a schematic diagram representation of a 
vehicle sharing system according to a preferred em- 
bodiment of the present invention; 
Fig. 2 is a flow chart representation of steps carried 
out to request, select and allocate a vehicle, accord- 
ing to embodiments of the present invention; 
Fig. 3 is a flow chart representation of steps carried 
out for secure access and for enabling vehicles in 
a fleet of shared vehicles according to embodi- . 
ments of the present invention; 
Fig. 4 is a flow chart representation of steps carried, 
out for vehicle trips according to embodiments of 
the present invention; 

Fig. 5 is a schematic perspective view of a vehicle 
carrier according to an embodiment of the present 
invention; 

Fig. 6 is a schematic perspective view of a vehicle 
distribution port facility according to an embodiment 
of the present invention. 

Fig. 7 is a generalized block diagram representation 
of a computer subsystem in a port facility according 
to an embodiment of the present invention; 
Fig. 8 is a schematic perspective view of a vehicle 
distribution port facility according to another em- 
bodiment of the present invention; 
Fig. 9 is a generalized block diagram representation 
of a central facility according to an embodiment of 
the present invention; 

Fig. 10 is a generalized block diagram representa- 
tion of a vehicle subsystem according to an embod- 
iment of the present invention; 
Fig. 1 1 is a graph of the state of charge of a vehicle 
battery versus charge time curve; and 
Fig. 12 is an illustration of a transfer of vehicles be- 
tween ports; 

Fig. 1 3 is an illustration of a preferred embodiment's 
mounting of a identification card reader and a PIN 
entry console; 

Fig. 1 4 is a block diagram illustrating a central office 
computer system and the subsystem kiosk comput- 
ers linked to the central office computer system 
through the Internet; and 

Fig. 1 5 is a flow diagram of the process when a user 
seeks a shared vehicle and interacts with a kiosk 
computer. 

DESCRIPTION OF THE REFERRED EMBODIMENT 

[0022] In the following description of preferred em- 
bodiments, reference is made to the accompanying 
drawings which form a part hereof, and in which is 
shown by way of illustration a specific embodiment in 
which the invention may be practiced. It is to be under- 
stood that other embodiments may be utilized and struc- 
tural changes may be made without departing from the 
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scope of the preferred embodiments of the present in- 
vention. 

[0023] The present invention relates, generally, to 
systems and methods for sharing a fleet of vehicles 
among a plurality of users, and various aspects of such -s 
systems and methods including optimizing vehicle allo- 
cation, vehicle tracking, security, and charging and man- 
aging of shared electric vehicles. As discussed above, 
in a shared vehicle system, a number of vehicles are 
normally maintained in several designated parking are- 10 
as. Each user is allowed to pick up a vehicle at one park- 
ing area, and return the vehicle to the parking area near- 
est to the user's destination or return the vehicle to the 
same designated parking area. 

[0024] To successfully attract people to subscribe and is 
become users of a shared vehicle system, the system 
must be sufficiently convenient and inexpensive. More 
particularfy, users should be able to pick up a vehicle at 
a convenient location and with minimal or no waiting 
time. The system should be easy and inexpensive for 20 
the user and cost effective for the system administrator 
to operate. To have minimal environmental impact, the 
system should be capable of addressing the above 
needs and employing clean means of transportation, 
such as electric powered vehicles, as its primary shared 2$ 
vehicle. 

[0025] Preferred embodiments of the present inven- 
tion relate to shared vehicle systems and methods 
which address the above-described needs and which 
address additional needs and provide additional acrvan- 30 
tages discussed below. As will become apparent from 
the discussion below some embodiments pertain only 
to sharing systems containing at least some electrical 
vehicles. Those embodiments of the invention relate to 
charging or state of charge (SOC) of electric vehicles 35 
and may be implemented with or without various other 
aspects relating to, for example, vehicle allocation, 
tracking, and securing. Similarly, embodiments of the in- 
vention relating to vehicle allocation aspects may be im- 
plemented with or without various other aspects such 40 
as vehicle charging, tracking and securing, and embod- 
iments relating to vehicle securing may be implemented 
with or without other aspects such as vehicle tracking, 
allocation or charging. 

[0026] A schematic representation of a shared vehicle 
system 10 according to a preferred embodiment of the 
present invention is shown in Fig. 1. A system 10 ac- 
cording to the Fig. 1 embodiment includes a central fa- 
cility 12, at least one vehicle distribution port facility 14 
and a plurality or fleet of vehicles 16 (one of which is so 
shown in Fig. 1), each having a vehicle subsystem 18. 
In general, the central station and port facility and the 
vehicle subsystems communicate in a manner to allow 
a user 20 to enter information at a port facility 14. That 
information is then communicated to the central facility 55 
1 2, where the information is processed to select a vehi- 
cle from the fleet to allocate to the user at the port facility 
14. The central station 12 communicates with the port 



facility 14 and the vehicle subsystem 18, according to 
various embodiments described below, to notify the user 
of the selected vehicle, to provide secure user access 
to the selected vehicle, to monitor the location and op- 
erating status of vehicles in the fleet, to monitor the state 
of charge of electric vehicles and to provide other func- 
tions described below. 

Selection and Allocation off Sharing Systems 
Containing Electric Vehicles: 

[0027] According to one aspect of the present inven- 
tion, systems and methods for sharing electric vehicles 
involve selecting and allocating vehicles to users, based 
on a combination of factors for maximizing efficiency 
and user-convenience. Such factors may include vari- 
ous combinations of the following: the location of the ve- 
hicles within the fleet, state of charge of the vehicles, 
the distance which the user expects to travel, the period 
of time that the user expects to use the vehicle, the us- 
er's expected destination, statistical analysis of vehicle 
use patterns and the identity of the user, the number of 
individuals waiting for vehicles in the port, and the 
number of vehicles present in the port. 
[0028] A user desiring to obtain the use of a vehicle 
16 arrives at a first port facility 14 and enters a request 
for a vehicle and other information into a computer sys- 
tem. The information may include the destination port 
or kiosk. The information may also include the additional 
distance and/or time that the user expects to travel be- 
yond the normal distance and/or time to reach the des- 
tination port facility, for example, to conduct errands or 
other excursions. The information may further include 
user identification information, for example, read from a 
card key 21 , smart card, magnetic strip, fingerprint, ret- 
inal scan or other, machine-readable method of identifi- 
cation. 

[0029] In a preferred embodiment, described with ref- 
erence to the system in Fig. 1 and the flow chart of Fig. 
2, a user enters identification information by swiping a 
card key 21 (or other machine-readable token) past a 
reader, step 22. The information is received by the sys- 
tem in step 24 and, in step 26, the user enters travel 
information (such as destination, added distance and/or 
added time) with a keyboard, touch-screen, mouse or 
other suitable user interface. In step 27 the availability 
of a vehicle is checked, and if a vehicle is available step 
28 follows, if not step 40 will be next. 
[0030] In the present preferred embodiment, the com- 
puter system at the port facility 14 is programmed to 
prompt the user to enter the above-noted travel infor- 
mation, upon the user registering by swiping the card 
key 21 (or other token) past the reader. The computer 
system may display destination options and/or addition- 
al time or distance options. Thus, the display may 
prompt the user to, for example, select or click an icon 
for a proposed destination port facility. In addition other 
icons for selecting a proposed additional number of mtn- 
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utes or miles of expected travel beyond the route to the 
destination port may be displayed. By selecting the ad- 
ditional icons the user may inform the system that the 
user will have an errand trip. An errand trip is a detour 
from the regular route that would be taken in traveling 
between points. For example a user of a vehicle may 
travel directly to a destination or they may take a side 
excursion for example to pay a bill or to buy a newspa- 
per. Such side excursions are errand trips. The user can 
select different icons notifying the system that, for in- 
stance an errand trip will take an additional 45 minutes 
and add an additional 10 miles beyond what would be 
expected if the direct route to the destination were taken 
without the errand trip. In yet further embodiments, a 
map is displayed to the user and the user is prompted 
to identify locations on the map corresponding to a des- 
tination and/or side trip locations or zones. It can be very 
important to the scheduling and allocation of vehicles to 
allow for excursions such as errand trips. Efficient allo- 
cation of vehicles is easier if vehicle trips can be pre- 
dicted with greater reliability and accuracy. Embodi- 
ments of the vehicle sharing system and method include 
implementations. which reward users for accuracy, for 
example if the user returns the vehicle within 5 minutes 
of the planned return time the user may get an "accurate 
return time" discount. Users may also get a discount if 
they give notice of unexpected delays. For example if 
the users were charged a per hour rate a user would be 
charged for a whole hour if they returned a vehicle 10 
minutes late, whereas if they gave notice of their late 
return, so that the vehicle could be reallocated during 
the proper time frame, they might be charged for only a 
portion of an hour. Similar discounts might be given for 
accurately predicting the number of miles driven. By ac- 
curately predicting the distance to be driven the system 
could more accurately predict, at the beginning of a trip, 
the state of charge (for electrical vehicles) that will be 
present when a vehicle is returned, thus enabling more 
efficient allocation of vehicles and charge facilities. 
[0031] The information entered by the user at a port 
facility 14 is communicated to the central facility 12. In 
addition, the central facility 12 receives information 
transmitted from the vehicle subsystem 18 in each ve- 
hicle 16, relating to the location, parking state, odometer 
information, state of charge SOC of the vehicle, trip time, 
and various other trip information and statistics. Based 
on the information received from the first port facility 14 
and from the vehicle subsystems 18, the central facility 
1 2 selects a vehicle from among the fleet to allocate to 
the user, as shown in step 28 in Fig. 2. 
[0032] To select a vehicle, a vehicle search group is 
defined for the first port facility. The vehicle search group 
preferably includes vehicles 16 located and parked at 
the first port facility 14 that are not presently allocated 
to other users. The vehicle search group may also in- 
clude vehicles 16 expected to arrive at the first port fa- 
cility within a pre-defined time period. Vehicles sched- 
uled to leave the port for transfer to another port or oth- 



erwise can be removed from the vehicle search group, 
as can vehicles that have insufficient SOC for the in- 
tended use. The pre-defined time period is preferably 
selected to minimize user-waiting time, yet maximize 
vehicle usage efficiency, or minimize energy usage or 
vehicle emissions. A pre-defined time period of, for ex- 
ample, about ten minutes may be sufficient to improve 
vehicle usage efficiency, without significantly inconven- 
iencing users. 

[0033] Vehicles 16 with an insufficient SOC to make 
the trip to the expected destination, including any addi- 
tional distance and/or time entered by the user and an 
additional margin for error or unexpected travel may be 
excluded from the vehicle search group. Thus, a deter- 
mination is made of the total charge necessary to safely 
make the trip, based on the expected destination, addi- 
tional distance and/or additional time information en- 
tered by the user. The total necessary charge is com- 
pared with the SOC information received from vehicles 
present at the port facility or otherwise within the vehicle 
search group of the first port facility. Vehicles that have 
SOCs below the total necessary charge are excluded 
from the selection process. However, vehicles 1 6 which 
are in the process of being charged at the first port fa- 
cility 14 may be included in the vehicle search group, 
provided that they will be sufficiently charged within a 
pre-defined time period (which may be the same pre- 
defined time period as noted above or a second time 
period) as may vehicles arriving at the port form com- 
pleted trips, or from being transported to the port. 
[0034] If a group of more than one vehicle 1 6 is in the 
vehicle search group of the first port facility and has suf- 
ficient SOC to make the requested trip, then, according 
to one embodiment of the present invention, the vehicle 
with the highest SOC within the group is selected and 
allocated to the user. It has been found that selecting 
the higher SOC vehicles first, typically improves the ef- 
ficiency of the charging facilities by utilizing the charger 
in its more efficient linear range between 212 and 214 
(see Fig. 11). 

[0035] However, in the event that a user enters a re- 
quest to make a long distance trip and, thus, requires a 
vehicle having a relatively high SOC, it would be advan- 
tageous to have a relatively high SOC vehicle available 
for the user, without requiring the user to wait a long pe- 
riod of time. Accordingly, in further preferred embodi- 
ments, the vehicle having the highest SOC within the 
above-defined group is reserved for the long-distance 
user and the second highest SOC vehicle is allocated 
to other users. Of course, if the group consists of only 
one vehicle, then that vehicle is allocated to the user, 
rather than reserving the vehicle for a further prospec- 
tive long-distance user. 

[0036] While the above alternative embodiment refers 
to reserving the highest SOC vehicle within the defined 
group for a prospective long-distance user, other em- 
bodiments may reserve the highest and second highest 
SOC vehicle and so forth. Moreover, different numbers 
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of vehicles may be reserved for long-distance users de- 
pending upon the time of the day or the day of the week, 
statistical or simulated use patterns, vehicle reserva- 
tions, or a variety of other factors. In preferred embodi- 
ments, statistics of users driving practices and habits at 
each port facility can be collected and analyzed to de- 
termine the optimal number of vehicles which should be 
reserved for long-distance users for any given port fa- 
cility, day and time. In yet further preferred embodi- 
ments, the system and method switches between a rou- 
tine of selecting the highest SOC vehicle within the 
group and a routine of reserving one or more of the high- 
est SOC vehicles within the group for long-distance us- 
ers, based on expected usage patterns or statistical 
analysis of actual or simulated usage patterns 
[0037] A port facility can contain a plurality of charging 
facilities 169 that are used to recharge the batteries of 
electrical vehicles. Typically battery/charging systems 
for electrical vehicles have a characteristic as shown in 
the SOC versus time graph 210 as shown in Fig. 11. 
Between points 21 2 and 21 4 on the graph, the charging 
of the battery is essentially linear. Between points 214 
and 216, the charging of the battery approaches 100% 
charge exponentially and therefore the amount of 
charge obtained per unit time decreases. By allocating 
vehicles with a higher state of charge to users, instead 
of merely allocating vehicles with a sufficient charge for 
the users requested use, the vehicles within a central 
facility will tend to be used before the charge point 214 
on the graph is reached. By charging vehicles in the lin- 
ear region between 212 and 214, more effective use of 
the charging facilities is made than by charging vehicles 
in the range between 21 4 and 216. This method of allo- 
cating vehicles with the highest charge, however may 
be modified, as previously described, in order to provide 
vehicles for long trip use (i.e. vehicles charged between 
214 and 216 on the state of charge graph). In cases 
where vehicles for long trips are needed the vehicles 
with the second highest charge could be allocated for 
use in order to preserve the most highly charged vehicle 
for the long trip user. In cases where a greater demand 
for long trip vehicles was present, the vehicle with the 
second highest charge might also be reserved. The al- 
location of vehicles can be modified by statistical or sim- 
ulated vehicle use in order to make the most efficient 
use of charging facilities, while at the same time attempt- 
ing to accommodate the need for vehicles with high 
state of charge for long trips. 

[0038] Once a vehicle is selected based on the above- 
noted routines, the vehicle is allocated to the user and 
the particular vehicle is identified to the user, as shown 
at step 30 in Fig. 2. The vehicle may be identified to the 
user by identifying the location of the vehicle, e.g. a 
parking space number, or by a number, e.g. license 
plate, displayed on the vehicle. If the selected vehicle is 
due to arrive at the port facility or is due to be sufficiently 
charged at the port facility within the above-noted pre- 
defined time periods, then the user is notified of the ex- 



pected wait time and is asked if they will wait for the 
availability of the vehicle which will arrive at the port. In 
preferred embodiments, the user is provided with an op- 
tion to accept or decline, for example, by a displayed a 

5 command prompt to accept or decline the proffered ve- 
hicle. If the user declines the vehicle, step 32, the sys- 
tem returns to an idle condition to await the next user, 
step 34. If the user accepts the vehicle, step 36, the user 
may then pick up the vehicle at the port facility 14, step 

10 38. 

[0039] Vehicles may arrive at the port in two distinct 
ways. A vehicle may arrive at the port if the user com- 
pletes a trip and returns the vehicle to the port. A vehicle 
may also be relocated from another location. Fig. 12 is 

is an illustration of a transfer of vehicles between ports. An 
attendant drives a first vehicle 230. A second vehicle 
234 is towed behind the first vehicle 230, attached to the 
first vehicle via a towing mechanism 236. Couplings for 
the attachment of the towing mechanism may be in- 

20 stalled on the front and rear of shared vehicles (e.g. 230, 
234) so that any number of like vehicles may be con- 
nected in series for the purpose of relocating them from 
one port to another. The couplings installed on the ve- 
hicles may also be used to transport other vehicles. Fig. 

2$ 1 2 illustrates a motor scooter 240 being transported on 
the second vehicle 234. The Scooter 240 is mounted on 
a lifting mechanism 242 Other vehicles, for example a 
bicycle, or motorized bicycle may also be transported in 
a similar manner. If a port attendant tows a second ve- 

30 hide with a motor scooter, as shown in Fig. 1 2 then when 
the attendant has reached the destination port the at- 
tendant may uncouple the motor scooter and ride it back 
238 to the embarkation port, thus relocating two vehicles 
in one trip. The motor scooter may also have a carrying 

35 bracket for transporting towing mechanisms back to the 
origination port along with the attendant Electronic tow- 
ing mechanisms have also been demonstrated. Such 
mechanisms cause vehicles behind a lead vehicle to fol- 
low the lead vehicle through electronic means. Such 

40 electronic towing mechanisms however are still in the 
experimental stage, and no commercial systems are 
available. 

[0040] If no vehicles are within the vehicle search- 
group and have sufficient SOC to meet the user's needs, 

45 then the system determines that a vehicle may need to 
be relocated from another port facility to the first port for 
the user, as shown in step 40. In such an event, infor- 
mation is displayed to the user relating to the expected 
time of arrival of a relocated vehicle or user returned 

50 vehicle, step 42, and is provided with an opportunity to 
accept or decline to wait for the vehicle. If the user de- 
clines, step 44, then the system returns to an idle con- 
dition, step 34, and awaits the next user. If the user ac- 
cepts the wait time, step 46, then the user waits, step 

55 48 until the vehicle arrives, step 50. Upon arrival of the 
vehicle, the user is prompted to confirm the request for 
the vehicle. If the user does not confirm the request with- 
in a preset time period, for example, five minutes as 



7 



13 



EP 1 067 481 A2 



14 



shown in step 52, then the system returns to an idle con- 
dition, step 34. If, however, the user timely confirms the 
request, step 54, then the user may pick up the vehicle, 
step 38. 

[0041] Vehicles may be relocated from one port facil- s 
ity to another in a variety of manners. For example, an 
attendant may simply drive the vehicle from one facility 
to the other. However, the attendant performing the re- 
location would then be displaced from his original loca- 
tion. Accordingly, two attendants may drive two vehicles 10 
to from one port to the next, leave one vehicle at the 
destination port and then both attendants may return to 
their original port in the other one of the two vehicles. 
However, that process requires two attendants to trans- 
port a vehicle between facilities. Accordingly, in a pre- ---is 
f erred embodiment, some or all of the vehicles within 
the fleet are provided with towing bar connectors and 
each port facility is provided with towing bars for con- 
necting two vehicles together In this manner, one vehi- 
cle may be readily connected to another and towed to 20 
a remote port facility by a single attendant. The attend- 
ant may then disconnect the connected vehicles, leave 
one of the vehicles for the user and return to the original 
port facility with the other one of the two vehicles. Alter- 
natively a secondary vehicle, for example a motor scoot- 25 
er, may be secured to the second vehicle. The motor 
scooter can, upon delivery of the vehicles, be used to 
transport both the attendant and the towing bar equip- 
ment thus allowing the two connected vehicles to remain 
at the destination port while the attendant and the towing 30 
equipment depart. 

Controlling Access to Allocated Vehicles : 

[0042] According to another aspect of the present in- 3S 
vention, systems and methods for sharing vehicles in- 
volves controlling access to each allocated vehicle, so 
that access is allowed only for the user to whom the ve- 
hicle had been allocated. Security measures are imple- 
mented with the use of card keys (or other suitable ma- 40 
chine- readable tokens) and personal identification num- 
bers (PI Ns) issued to each user. Thus, according to this 
aspect of the invention, a user registers at a port facility, 
such as by swiping a card key (or other token) or by en- 
tering identification information through other suitable 
user interface means, such as described above with re- 
spect to step 22 of Fig. 2, and a vehicle is selected by 
the central facility. If the vehicle fleet includes electric 
powered vehicles, then the selection of the vehicle is 
preferably performed in accordance with the above de- 
scribed vehicle selection and allocation aspect of the in- 
vention. However, other embodiments may employ oth- 
er suitable selection routines. 

[0043] Once a vehicle is selected, identified and ac- 
cepted by the user, such as described above with re- 
spect to steps 28, 30 and 36, then the user's identifica- 
tion information is sent to the vehicle subsystem 18 in 
the selected vehicle from the central facility 12, as 



shown in step 56. In preferred embodiments, the infor- 
mation is encrypted for security and addressed to the 
vehicle subsystem of the selected vehicle. Upon receipt 
of the user identification information, the vehicle subsys- 
tem starts a counter for timing a preset time period, such 
as five minutes, as shown in step 58, and stores the 
identification information in memory, as shown in step 
60. 

[0044] Meanwhile, the user walks to the vehicle, such 
as in step 38. With reference to the flow chart of Fig. 3, 
if the user arrives at the vehicle within the preset time 
period, such as five minutes, the user then enters iden- 
tification information, for example, by swiping a card key 
(or other machine-readable token) past a reader mount- 
ed on the selected vehicle, step 62 in Fig. 3. In preferred 
embodiments, the card key (or token) is the same card 
key (or token) used during the user registration at the 
port faciirty. If the identification information (card key or 
token) is not read by the reader within the preset time 
period, then the user identification routine is disabled on 
the vehicle subsystem, step 64 and the vehicle is des- 
ignated as being available for further users, step 66. 
[0045] If, on the other hand* the user's identification 
information (card key or token) is read within the preset 
time period, step 68, then the vehicle subsystem com- 
pares the stored identification information received from 
the central facility with the identification information en- 
tered by the user (read by the card or token reader), as 
shown in step 70. If the identification information does 
not match, then the user is denied access to the vehicle, 
step 72. 

[0046] If the identification information received from 
the central facility matches the identification information 
(card key or token) entered by the user, then the user is 
allowed access to the vehicle, as shown in step 74 and 
a counter starts timing a preset time period, such as five 
minutes, as shown in step 76. In preferred embodi- 
ments, the vehicle subsystem employs an electronic 
door lock that is controlled to selectively unlock the ve- 
hicle, step 78, to allow access to the vehicle interior. In 
addition, counters within the vehicle subsystem are set 
and started for counting the number attempts of entering 
a personal identification number PIN, step B0, and for 
timing a preset time period by which a correct PIN must 
be entered, such as 200 seconds, step 82. 
[0047] After gaining access to the vehicle, the user 
enters the vehicle and closes the vehicle door, step 84. 
The user is provided with an opportunity to enter a PIN 
in a user interface and display device mounted, for ex- 
ample, in the center console, dashboard or overhead 
console of the vehicle. If the user does not enter the cor- 
rect PIN within a preset number of attempts, for exam- 
ple, five attempts, as shown in step 86, or within a preset 
time period, such as 200 seconds as shown in step 88, 
then the user's request for a vehicle is canceled, step 
90 and an error message is displayed on the user inter- 
face and display device, step 92. Thereafter, when the 
user leaves the vehicle, step 94, and closes the doors, 
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the doors are automatically locked, step 96, and the ve- 
hicle subsystem returns to an idle state, step 98. The 
vehicle is then made available for further users, as 
shown by the connection to step 66. If, on the other 
hand, the user enters the correct PIN within the preset s 
number of attempts and the preset time period, step 
100, then the vehicle subsystem enables the vehicle 
and the user may operate the vehicle, step 102. 
[0048] In one preferred embodiment both the user's 
identification data and PIN are read from a user's iden- 10 
tification card and communicated to the vehicle to be 
allocated to the particular user. As scon as the user's 
identification data and PIN are communicated to the ve- 
hicle to be allocated to the particular user, an authorized 
user may drive the vehicle on a trip without any further is 
communication between the vehicle and the central fa- 
cility. Upon use of the proper identification card and en- 
try of a correct pin within the vehicle, the vehicle is ready 
to drive. The identification card reader 246 may be lo- 
cated on a window as shown Fig. 1 3. The PIN entry is 20 
accomplished by means of an input and display device, 
which may be mounted in a center console within the 
vehicle as shown in Fig. 13. In another preferred em- 
bodiment, the determination of whether the entered PIN 
is correct or not is made at the central facility, for addi- 25 
tional security. In this case the valid pin is not sent to the 
vehicle, instead the user in the vehicle enters a PIN 
which is then sent to the central facility for validity de- 
termination. If the PIN is valid then the central facility 
sends a notification of valid PIN to the vehicle. In partic- 30 
ular, the central facility 12 preferably includes or oper- 
ates with a database, table, algorithm, number encoded 
on the user's identification card, or the like which asso- 
ciates each user's identification information (card key or 
token) with the user's personal identification number 3$ 
PIN. Accordingly, upon receiving the requesting user's 
identification information, the central facility 12 obtains 
that user's PIN, for example, by comparing the identifi- 
cation information with corresponding data base entries 
and reading PIN information associated in a database *o 
with the identification information. Furthermore, when 
the user enters a PIN in the user interface and display 
device in the vehicle, steps 86 or 100, the vehicle sub- 
system transmits the entered PIN to the central facility. 
The central facility then compares the PIN received from 45 
the vehicle subsystem with the PIN retrieved from the 
database, table, algorithm, user's identification card, or 
the like. If a sufficient match exists, then the user is con- 
sidered to have entered a correct PIN. The central facil- 
ity may then send an enabling command to the vehicle, so 
acknowledging that a correct PIN has been entered at 
the vehicle and the vehicle may be driven. The correct 
pin can be maintained in the vehicle subsystem 18 for 
later identification of the user and enabling of the vehi- 
cle, even if the vehicle were not in communication with ss 
the central facility. 

[0049] Accordingly, preferred embodiments provide 
multiple levels of security. A first level of security is pro- 



vided by the fact that a valid ID card is required even to 
enter the port facility. A second level of security is pro- 
vided by the requirement that, a user must proffer the 
proper identification at the kiosk 1 4 to be assigned a ve- 
hicle. A third level of security is provided at the vehicle 
where the user must enter valid identification informa- 
tion (for example, by swiping a card key or token) to gain 
access to the vehicle. A fourth level of security is pro- 
vided by the requirement that, once the user gains ac- 
cess, the user must input a PIN that corresponds to the 
same user associated with the identification ^formation. 
Moreover, each of these entries must be made within a 
preset period of time. These multiple levels of security 
reduce the risk of unauthorized entry and unauthorized 
use or theft of the vehicles. Thus, users are provided, 
with a more secure environment within the vehicles and 
the vehicle owners and system administrators are pro- 
vided with a reduced risk of vehicle theft or misuse. 

Vehicle Trip and Condition Monitoring : 

[0050] In accordance with further aspects of the 
present invention, after the user engages the engine as 
discussed above with respect to step 102, the user may 
shift into drive, step 104 of Fig. 4, to begin the user's 
requested trip. During the course of the trip, the vehicle 
subsystem monitors various parameters associated 
with the vehicle, for example, the location of the vehicle, 
the state of charge SOC of the vehicle (in electrical ve- 
hicles) and other operational parameters such as odom- 
eter reading, speed, and actual usage or drive time, as 
shown in step 106. Information, including location infor- 
mation, SOC and other operational information, such as 
whether the vehicle is moving and if so at what speed, 
whether the vehicle is charging, the odometer reading, 
the state of charge of the battery system, is preferably 
transmitted from the vehicle subsystem 18 to the central 
facility 12 at periodic or non-periodic intervals. In this 
manner, the central facility may readily track each vehi- 
cle in the fleet and render selection and allocation de- 
terminations based on vehicle location and SOC infor- 
mation for each vehicle, as described above. In addition, 
the central facility may monitor the SOC of fleet vehicles 
for purposes of warning users and port facility attend- 
ants to re-charge a vehicle. 

[0051] The user interface and display device within 
the selected vehicle displays various information to the 
user, for example, usage time, or warnings relating to 
the SOC or other vehicle parameters, notices or travel 
information sent from the central facility, as shown in 
step 108. For example, the central facility may send a 
warning to a vehicle, to inform the user that the SOC of 
the vehicle is low or has experienced an unusual fluctu- 
ation. The user may be informed to return the vehicle to 
the nearest port or kiosk or to simply connect the vehicle 
to a charger, upon the user's scheduled return. 
[0052] The user interface and display device within 
the selected vehicle may also be used to transmit mes- 
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sages to the central facility. A group of preset messages 
such as flat tire", "vehicle inoperative" or "send help" 
may be transmitted from a user interface and display 
console within the vehicle by the user selecting which 
message to transmit to the central facility. . 
[0053] In further preferred embodiments, the vehicle 
subsystem may include or operate with a locator such 
as global positioning system (GPS), dead reckoning 
system, radio beacon triangulation system, or a variety 
of other techniques for providing tracking and route in- 
formation. The user interface and display device may 
be used to display map and route information, in accord- 
ance with well known tracking and routing systems. 

Vehicle Parking and Return : 

[0054] At some point in the duration of the user's trip, 
the user will stop the vehicle and place the vehicle in a 
parking gear as shown in steps 110 and 1 1 2. In preferred 
embodiments, the vehicle subsystem 1 8 includes a sen- 
sor system for sensing such an event. Upon sensing that 
the transmission is set in a parking state and/or the ig- 
nition or power is turned off, the vehicle subsystem 18 
transmits a parking state signal to the central facility. 
Once the vehicle is placed in a parking state, the vehicle 
is turned off and disabled, as shown in step 114, until 
the user reenters the correct user identification and cor- 
rect PIN. If the vehicle is at a port facility however and 
the vehicle is placed in a parking state, the vehicles is 
turned off and disabled, the user must go through the 
vehicle allocation process again if they desire to use a 
vehicle further. At the port the vehicle is returned to the 
pool of available vehicles when it is placed in the park 
state. 

[0055] In further preferred embodiments, the vehicle 
subsystem 18 includes or operates with sensors for 
sensing the user exiting the vehicle, step 116, such as 
sensors for sensing the driver-side door opening and/or 
closing after the vehicle is set in a parking gear. Further 
embodiments may employ other suitable sensors for 
sensing a parking condition, including, but not limited to 
a pressure sensor for sensing presence of weight on the 
driver's seat, a sensor for sensing the setting of the park- 
ing brake, or the lack of motion for a predefined period 
of time, or combinations thereof. In yet further embodi- 
ments, the user may simply enter a notice indicating that 
the vehicle is parked in the user interface and display 
device in the vehicle. 

[0056] Information relating to the parked state of the 
vehicle is transmitted from the vehicle subsystem to the 
central facility. However, further information is needed 
to determine whether the vehicle is parked and being 
returned to a port facility or is merely temporarily parking 
while the user is conducting an errand. Accordingly, in 
preferred embodiments, if the vehicle is in a parked 
state, then the vehicle's location is determined, as 
shown in step 118. As discussed above, any suitable 
vehicle tracking system may be employed to track and 



determine vehicle locations, including, but not limited to, 
GPS systems, a Teletrac system (Te' e * rac *s a trade- 
mark of Teletrac, Carlsbad California), or the like. 
[0057] If the vehicle is determined to be within a port 
5 facility when placed in a parked condition, then the ve- 
hicle subsystem is controlled to lock the vehicle doors 
within a preset time period, for example, 30 seconds, 
after the last vehicle door is closed, step 120. The vehi- 
cle subsystem then returns to the idle condition, step 
10 1 22, and awaits allocation to a further user. 

[0058] If the vehicle is determined to be outside of a 
port facility when placed in a parked condition, then the 
vehicle subsystem is controlled to lock the vehicle doors 
and disable the vehicle within a preset time period, for 
example, 30 seconds, step 124. The vehicle subsystem 
also may be controlled to lock the vehicle doors after a 
door has been opened or after the ignition has been 
turned off. However, instead of returning to idle condi- 
tion, the vehicle subsystem remains programmed to al- 
low access and the enabling of the vehicle to the user 
with the same user identification and PIN, as shown in 
step 126. In this regard, when the user returns to the 
vehicle, the user may input the same identification data 
(for example, by swiping the same card or token) there- 
by entering the same PIN that was previously entered 
by the user or sent to the vehicle via the central system, 
as shown in step 1 28. Thereafter, the process of com- 
paring identification information and processing PIN in- 
formation is carried out similar to that described above 
with respect to Fig. 3, beginning at step 70. 
[0059] Thus, in accordance with a further aspect of 
the present invention, the parking state of each vehicle 
1 6 is sensed and a determination is made as to whether 
the vehicle has been returned or is merely temporarily 
parked during a user's trip. The identification information 
and PIN data required to access the vehicle remain the 
same, unless it is determined that the vehicle has been 
returned and parked at a port facility. Accordingly, a ve- 
hicle may be automatically reallocated to another user 
upon the determination that the vehicle has been parked 
and returned to that facility. 

Safety and User Errors : - 

4S [0060] According to further aspects of the present in- 
vention, safety measures are implemented to address 
situations in which a legitimate user inadvertently enters 
the wrong PIN more than the allowed number of at- 
tempts, fails to enter the information within the preset 

so time period, loses a card key or locks the card key inside 
of the vehicle. In the event that a legitimate user is in- 
advertently denied access to or enablement of a vehicle, 
then the user may contact the central facility by suitable 
means; including, but not limited to, telephone, portable 

ss internet connection, or other communication device. 
Upon verification of the user's identity, the central facility 
transmits a command to the user's vehicle to instruct the 
vehicle subsystem to unlock and enable the vehicle for 
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the user. If the user is at a remote location from the ve- 
hicle, for instance at a public telephone, the enablement 
command may have a delayed enabling effect in order 
to allow the user to return to the vehicle before it is en- 
abled. 

[0061] User identity may be verified, for example, by 
requesting that the user provide certain personalized in- 
formation for comparison with such information ob- 
tained from the user when the user originally subscribed 
to the system. Inaddition, the location of the vehicle may 
be determined, as noted above, and may be compared 
with the expected vehicle location, based on the travel 
information entered by the user upon requesting the ve- 
hicle. 

[0062] In addition the vehicle possesses a "fail safe" 
operations mode. Once a vehicle is checked out by a 
user it will continue to operate for the balance of the us- 
er's trip, even if the communications unit which main- 
tains communication with the central facility should fail, 
or should the central facility cease function for any rea- 
son. Thus there is no condition where toss of communi- 
cations between the central facility and the vehicle will 
cause the vehicle to become disabled. 
[0063] The vehicle may also be disabled in some cir- 
cumstances, such as when the vehicle is reported as 
stolen, or when proper authorities seek to immobilize the 
vehicle. The vehicle may also be enabled in an emer- 
gency, for instance if the vehicle is in danger of being 
damaged if it is not moved, such as a spreading fire in 
a nearby facility. 

Vehicle Relocation : 

[0064] As discussed above, in preferred embodi- 
ments, vehicles may be relocated from one port facility 
to another, to meet user demands or to relieve a facility 
of an oversuppry of vehicles. Also as discussed above, 
in a preferred embodiment, some or all of the vehicles 
within the fleet are provided with towing bar connectors 
and each port facility is provided with towing bars for 
connecting two or more vehicles together. In this man- 
ner, one vehicle may be readily connected to another 
and towed to a remote port facility by a single attendant. 
The attendant may then disconnect the connected ve- 
hicles, leave one of the vehicles for the user and return 
to the original port facility with the other one of the two 
vehicles, or on a vehicle, for example a motor scooter, 
mounted on one of the vehicles. 
[0065] The ability to connect vehicles, relocate the 
connected vehicles and disconnect the vehicles at the 
relocation in a time efficient manner requires a tow bar 
and connection system that can be operated quickly and 
easily. Accordingly in preferred embodiments some or 
all of the fleet vehicles are provided with tow bar con- 
nectors and each port facility is provided with at least 
one tow bar designed for quick and easy connection to 
the vehicles. The relocation aspect becomes more com- 
plex, however, when the fleet of vehicles includes a va- 



riety of different types of vehicles, such as four-wheel 
vehicles, two-wheel vehicles, and/or three-wheel vehi- 
cles. In such embodiments, it is preferred that a tow or 
carrier mechanism be provided to allow various types of 

s vehicles to be towed or carried by other fleet vehicles 
from one port facility to another. 
[0066] Thus, for example, Fig. 5 shows an example 
of a carrier bracket 1 30 for connection to a standard tow 
bar receptacle on the rear of a vehicle, and which is con- 

10 figured to carry a further vehicle, such as a two-wheeled 
or three-wheeled vehicle. More particularly, the bracket 
1 30 includes a first "L"-shaped member 1 32 and a sec- 
ond, smaller "L" -shaped member 134 coupled in a slid- 
ing relationship with the first member 132. Each "L" 

15 shaped member 1 32 and 1 34 includes a vertical leg and 
a horizontal leg. The vertical leg of the member 134 is 
coupled, by brackets 1 36 to the vertical leg of member 
132 and is slidable in the direction of arrow 138. along 
the vertical dimension. The vertical leg of member 134 

20 js connected to a flexible band 140. The opposite end 
of the strap 140 is wound around a spool or reel 142. 
[0067] In operation, the horizontal leg 144 of member 
1 32 is shaped to fit within and connect to the standard 
tow bar receptacle on the back of at least some of the 

25 fleet vehicles. The horizontal leg 1 46 of member 1 34 in- 
cludes a key or pin receptacle aperture 148 and is con- 
figured to couple to an inverted "U"-shaped bracket 
mounted to the underside of the vehicle 1 6' to be carried. 
For example, Fig 5 shows an inverted "U "-shaped 

30 bracket 150 mounted to the underside of a motorized 
two-wheeled vehicle. The bracket 150 defines a ■IP- 
shaped opening for receiving the horizontal leg 146 of 
the member 134. Apertures 152 in the bracket 150 are 
positioned to align with aperture 148, upon the bracket 

35 150 receiving the horizontal leg 146 of member 134. 
With the apertures aligned, the pin 154 may be inserted 
through the bracket 150 and leg 148, to secure the ve- 
hicle 1 6' to the carrier bracket 1 30. Accordingly the ve- 
hicle 16' may be carried by a vehicle 16, by simply con- 

40 necting the leg 144 to the standard tow-bar receptacle 
of a vehicle 16, then placing the vehicle 16* on the hor- 
izontal leg 146 and inserting the pin 154 through the ap- 
ertures 148 and 152. Finally, the vehicle 16' may then 
be lifted by rotating the spool or reel 1 42to take up some 

45 of the flexible band 1 40 and, thereby, draw the bracket 
1 34 in the vertically upward direction. The raising and 
lowering mechanism just described may be replaced by 
a variety of lifting mechanisms known in the art. For ex- 
ample the lifting mechanism provided may be a hydrau- 

so lie, pneumatic, rack and pinion, scissors and screw, or 
other mechanisms known in the art. 
[0068] After relocating the vehicles 1 6 and 1 6', the ve- 
hicle 16* may be detached from the bracket 130 by re- 
moving pin 54 and lifting the vehicle 16' off of the hori- 

55 zontal leg 1 46. If needed, the member 1 34 may be tow- 
ered by unwinding the spool or reel 142 to assist in re- 
moving the vehicle 16'. The bfting mechanism can ena- 
ble someone to transport a vehicle that would otherwise 
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be too heavy for an individual to lift onto a vehicle carrier 
without the lifting facility. 

[0069] In preferred embodiments, many of the func- 
tions of the port facility computer system, the central fa- 
cility and the vehicle subsystem described above with * 
respect to the flow charts of Figs. 2-4 can be implement- 
ed by programmable computers and processors. Em- 
bodiments of programmable computer or processor 
based facilities and vehicle subsystems are described 
below with reference to Figs. 6 - 10 as representative io 
examples. However, it will be understood that the sys- 
tem and methods according to the present invention 
may be .implemented in various combinations of hard- 
ware and software configurations and are not limited to 
specific example configurations described herein. is 

Port Facility: 

[0070] In preferred embodiments, the system 10 in 
Fig. 1 includes a plurality of port facility 14 located in 20 
geographically remote locations relative to each other, 
for example, at locations convenient for a large number 
of potential users, such as near train or bus stations, 
campuses, office parks, shopping areas or the like. Two 
examples of vehicle distribution port facility 14 are 2s 
shown in Figs. 6 and 8, respectively. In the example em- 
bodiments of Figs. 6 and 8, the vehicle distribution port 
10 facility includes parking spaces 156 for parking a plu- 
rality of vehicles 16. In addition, the distribution port 10 
includes a computer subsystem 1 58 typically located at 30 
a kiosk 14 to facilitate user interaction. Fig. 7 shows a 
generalized block diagram representation of the com- 
puter subsystem 158, which includes a computer 160, 
a display and user interface device 1 62, and a commu- 
nications interface 164 for communication with the cen- 35 
tral facility 12. The communications interface 164 may 
be, for example, a satellite, radio frequency RF or other 
wireless link, in which case, the interface 1 64 would in- . 
elude a transmitter/receiver. In a preferred embodiment 
of the invention, the interface 164 between the central 40 
office facility and the subsystem 158 may comprise a 
hard wired connection, such as through computers 
linked to the Internet. Such a preferred embodiment is 
illustrated in Fig. 14. In Fig 14 the user's interface to the 
system is a kiosk containing a computer, display screen, *s 
and one or more input devices such as a card reader 
and a keyboard and touch screen. A kiosk computer 250 
serves as a web client connected to the Internet. The 
system control computer 254 serves several functions, 
for example as the registration web-server 256 process 50 
computer, it also provides a monitoring and control proc- 
ess 264 for the system. The registration web-server 256 
serves the kiosk 250 computer web clients. The regis- 
tration web-server 256 also allows access to. the regis- 
tration web-server 256 by other computers connected ss 
to the internet. Having a web connection not only sim- 
plifies the connection of the kiosk 250 computer(s) to 
the system by allowing the kiosk web clients 250 to be 



located anywhere there is a ready connection to the in- 
ternet, it allows access to the vehicle sharing system 
from other Internet connected computers. This is valu- 
able for users of the system because they may access 
the system remotely, for example to make reservations 
for shared vehicles, to determine if vehicles are availa- 
ble at a port, to determine how long a wait there is for a 
vehicle, to apply for membership in the vehicle sharing 
system or for other reasons. 

[0071] The registration web-server 256 also interfac- 
es with a database 258. The database 258 contains user 
data 266, in which is kept a record of user information 
and statistics, such as the time and date that the user 
used the system, the user ID, the destination of the past 
trip, vehicle information, port information, as well as the 
time and distance estimates entered by the user for the 
past trips. These statistics can be used to predict vehicle 
usage, for example if a user makes a reservation for a 
shared vehicle. The database 258 may contain a user 
request database 268, in which user requests for vehi- 
cles and allocation information of the vehicle may be 
kept, as well as a wait request data 262. The wait re- 
quest data 262 may contain information about vehicle 
requests that cannot be immediately filled, for lack of a 
vehicle or in the case that the vehicle is, for instance an 
electrical vehicle, lack of a vehicle with sufficient battery 
charge. The wait request data 262 may contain such in- 
formation as the time and date that the user used the 
system, the user ID, the destination of the past trip re- 
quested as well as the time and distance estimates en- 
tered by the user for the trip requested. In one embodi- 
ment the wait request data may be on a separate com- 
puter and may be accessed by a user having the proper 
database permissions 260. Safeguarding the wait re- 
quest database 262 is important because the monitoring 
and control process 264 within the system control com- 
puter 254 uses the wait request data 262 to allocate ve- 
hicles to users who are waiting for vehicles. 
[0072] Fig. 15 is a flow diagram of the process when 
a user seeks a shared vehicle. As the user approaches 
the kiosk the system is idling, block 270. The user then 
swipes their identification card at the kiosk card reader 
as in block 272. The card read by the kiosk card reader 
is the same card as used at the vehicle to gain entry, 
and is also the same card used to gain access to the 
kiosk area. The kiosk computer then accesses the reg- 
istration web server in block 274. When communication 
has been established between the registration web 
server 256 and the kiosk web client 250 computer, block 
276 is executed. In block 276 user identification infor- 
mation, which has been obtained from the identification 
card, along with a kiosk ID identifying the transmitting 
kiosk, is sent to the registration web server Next in block 
278 the registration web server 256 compares the user 
ID received from the kiosk web client 250 computer to 
the active user list to see if the user is an authorized 
user. If the user ID is invalid, block 282, the user is told, 
in block 283, that their user ID is not valid and the system 
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returns to the idle state in block 270. If the User ID is 
valid, block 280, then the registration web server 256 
collects the user request information in block 2B4. The 
user request information consists of information such as 
vehicle destination, estimated time of the trip, and esti- 
mated distance of the trip. When the user information 
has been collected the registration web server 256 que- 
ries the shared system database, in block 286, in order 
to satisfy the request. In block 288 the registration web 
server 250 selects an available vehicle from the data- 
base 258 to satisfy the user request. In block 290 the 
user is asked if they accept or decline the offered vehi- 
cle, If the user declines the vehicle, block 294, the reg- 
istration web server 256 disconnects as seen in block 
296. If the user accepts the vehicle,, in block 292, the 
registration web server 256 stores the trip request data 
in the shared vehicle database in block 298. Finally in 
block 300 a computer control process polls the vehicle 
request database and processes the request. 
[0073] The computer subsystem 1 58 is preferably dis- 
posed in a well lit and highly visible location and, more 
preferably, is also housed within a building or enclosed 
structure 166 (as shown in Fig. 2), to which access is 
controlled for user security. Access may be controlled 
by an attendant stationed at the port facility 14 or by a 
standard lock and key system, wherein a key to the door 
168 is issued to each user. However, in preferred em- 
bodiments, the door lock is controlled by a card key entry 
system and each user is issued a card key comprising 
a card on which magnetic, optical or other machine- 
readable data is recorded. In such systems, the en- 
closed structure 1 66 is provided with an electronic door 
lock 170 (Fig. 7) and a card reader 172 disposed in a 
user accessible location outside of the structure 166, for 
example, adjacent the door 168. 
[0074] To gain entry to the structure 1 66, a user must 
swipe or insert the user's card key past or in the card 
reader 172, to allow data from the card to be read and 
communicated to the computer 160. The computer 160 
is programmed to process the user ID and, provided us- 
er ID is in the database of currently valid users, controls 
the electronic door lock 170 to unlock the door 168 and 
allow the user to enter the structure 166: For example, - 
the data may comprise a user identification code or an 
expiration date code and the computer 160 may be pro- 
grammed to compare user identification code with a da- 
tabase of valid user identification codes or compare the 
expiration date code with the current date. "Rius, the 
computer 160 may be programmed to unlock the door 
172, only if the user identification code is valid or an ex- 
piration date has not passed. 

[0075] Once the user has entered the structure 166, 
the user will have access to the port facility display and 
user interface device 162. The display and user inter- 
face device 162 may comprise any suitable display in- 
cluding, but not limited to, a cathode ray tube CRT dis- 
play, liquid crystal display LCD or the like, and any suit- 
able user interface, including, but not limited to, a touch- 



screen integrated with the display, a keyboard, a mouse, 
a joy stick or the like. For user convenience, a CRT dis- 
play with a touch-screen user interface is preferred. 
[0076] The display and user interface 1 62 is provided 
to display instructions, prompts and information to the 
user and to allow the user to enter information, such as 
travel information and/or identification information, from 
the users ID card, for processing by the computer 160 
or communication to the central facility 12. For added 
security, a second card reader (also represented by box 
172 in Fig. 7) may be disposed within the structure 166, 
adjacent the display and user interface 1 62, for the user 
to enter card key data to initiate or continue interaction 
with the display and user interface 162. As described 
. above, travel-information and/or identification informa- 
tion entered by a user at a port facility 14 is communi- 
cated to the central facility 1 2 and is used by the central 
facility to select a vehicle for the user to pick up at the 
port facility 14. 

[0077] In the Fig. 8 example, the vehicle parking spac- 
es 156 are located within an enclosed structure, such 
as a building 1 74 having a gate or passage 1 76 through 
which vehicles may enter and exit, for added vehicle se-r 
curity. In addition, the Fig. 8 example includes tracks 1 78 
for automated movement of vehicles between parking 
spaces 156 and the gate or passage 176. Thus, for ex- 
ample, a vehicle selected for a user 20 at the port facility 
may be automatically moved from a parking space 156 
and delivered to the gate 176 for pick up by the user. 
Similarly, upon completion of a trip or upon delivery of 
a vehicle to the gate 176 of the port facility, the vehicle 
may be automatically moved from the gate to a parking 
space 1 56. 

[0078] In preferred embodiments, the vehicle fleet in- 
cludes or is composed entirely of electric powered ve- 
hicles. Accordingly, each of the vehicle distribution port 
facility examples shown in Figs. 6 and 8 includes vehicle 
charging devices located adjacent at least some of the 
parking spaces. In the Fig. 8 example, the charging units 
may include automated connectors, for automatically 
connecting and disconnecting from vehicles in the park- 
ing spaces 156. 

Central facility : 

[0079] A generalized block diagram representation of 
an example central facility 12 is shown in Fig. 9. The 
central facility 12 in Fig. 9 includes a computer 180 with 
an Internet connection 13, programmed for processing 
user travel and/or identification information received 
from vehicle distribution port facility and selecting vehi- 
cles for users, based on the received information. The 
central facility 12 also includes a transmitter/receiver 
unit 1 82 for communication with the vehicle subsystems 
18, for example using a satellite communication link, an 
RF link or other suitable wireless link. As descrtoed 
above, the central facility 1 2 is also coupled for commu- 
nication with the computer subsystems 158 at the vehi- 
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cle distribution port facility. That communication link may 
also be made through the transmitter/receiver unit 182 
or, alternatively, through a separate communications 
link such as a hard wired link. 

[0080] As discussed above, the computer 1 80 is pref- 
erably programmed to conduct vehicle tracking rou- 
tines, for example, in accordance with standard vehicle 
tracking and communication software, including, but not 
limited to a Teletrac system (Teletrac is a trademark of 
Teletrac, Carlsbad California). Accordingly, the central 
office facility 12 also includes display devices 184, for 
providing a system administrator with visual information 
regarding the location and also regarding various mon- 
itored operational conditions of vehicles in the fleet, and 
an input device 186, such as a keyboard, mouse, or the 
like, for allowing the system administrator to input in- 
structions and data. Preferably, the central office facility 
is located in a secure environment, such as a secure 
office building, where data relating to user identification 
codes and other sensitive or private information may be 
maintained in a secure manner. 

Vehicle Subsystem : 

[0081] As described above, each vehicle 16 in the 
fleet is provided with a vehicle subsystem 18 for com- 
municating with the central office facility 12 and for per- 
forming a variety of other functions, depending upon the 
embodiment of the invention. A generalized block dia- 
gram representation of a vehicle subsystem 1 8 is shown 
in Fig. 10. Each vehicle subsystem 18 includes a pro- 
grammable processor or computer 1 88 for processing 
information and controlling the operation of other com- 
ponents of the subsystem 18. The vehicle subsystem 
1 8 also includes a transmitter/receiver unit 1 90 for wire- 
less communication with the central facility, as dis- 
cussed above. The vehicle subsystem also includes a 
display and user interface unit 192. 
[0082] In embodiments in which the vehicles within 
the fleet are enclosed vehicles, such as those shown in 
Figs. 1 , 6 and 8, then the display and user interface unit 
1 92 is disposed within the enclosed interior of the vehi- 
cle, in a convenient location for access by a vehicle user, 
such as on the center console, dashboard or overhead 
console. 

[0083] The vehicle subsystem for enclosed vehicles 
also includes a card reader 1 96 mounted for access by 
a user from outside of the vehicle. Thus, for example, 
Fig. 6 shows a card reader 1 96 mounted to the inside 
of the passenger window, behind the driver's side door. 
To gain access to the vehicle selected for a user, the 
user must swipe the card key past the card reader, to 
al tow the data recorded on the card to be read. The data 
read by the card reader 1 96 is provided to the processor 
188 for comparison with data received from the central 
facility, through transmitter/receiver unit 190. The proc- 
essor 188 is programmed to control an electronic door 
lock 1 98 to unlock one or more vehicle doors and allow 



access to the vehicle interior, upon a sufficient match 
between the compared data. - 

[0084] Once the vehicle door is unlocked, the user 
may enter the vehicle and gain access to display and 
s user interface 192. The processor 188 is programmed 
to operate with the display and user interface 1 92 to dis- 
play instructions to the user and to receive data input by 
the user, including a personal identification number PIN. 
The processor 188 is further programmed to enable or 
disable the operation of the vehicle by providing an en- 
able or disable signal 200 to an operation-critical ele- 
ment, based on the validity of the PIN entered by the 
user. The enable or disable signal may be used to con- 
trol a suitable device for enabling or disabling any oper- 
ation-critical element of the vehicle, including, but not 
limited to, the vehicle ignition system or fuel line {for in- 
ternal combustion powered vehicles), the battery power 
source, or the like. Devices which respond to enable or 
disable signals for enabling or disabling ignition sys- 
tems, fuel lines, battery power sources or the like are 
well known in the vehicle security field. In the case of an 
electric vehicle, for example, a disable signal would be 
activated by the vehicle being in a charging state. This 
would prevent the vehicle from being driven while it was 
connected to the charging facilities, thus eliminating 
damage that could be caused if the vehicle were acci- 
dentally driven while still connected to the charging fa- 
cilities. 

[0085] In further embodiments of the invention, the 
vehicle subsystem includes one or more parking state 
sensors 202, for sensing the parking state of the vehicle. 
As discussed above, the parking state of a vehicle may 
be sensed in various manners, including, but not limited 
to, sensing the setting of the transmission in the parking 
gear, the setting the parking brake, the lack of move- 
ment for a predetermined period of time, the opening 
and/or closing of a vehicle door or combinations of those 
events. In a preferred embodiment, a parking state is 
sensed by the combination of the vehicle being placed 
in a parking gear and the driver-side door being opened 
and vehicle speed being equal to zero. In such preferred 
embodiment, the parking state sensors 202 would, 
therefore, include a parking gear sensor for sensing the 
setting of the parking gear and a door sensor for sensing 
the opening and closing of the vehicle door. Other em- 
bodiments may contain various other methods for de- 
ciding that a user trip is over. For example the location 
of the vehicle at the port may be taken into account in 
order to determine that vehicle is in the parking state 
and the current trip has ended. There are several ways 
of determining that the vehicle is located at a port. The 
vehicle location system may place the vehicle at the 
port, the vehicle identity may be read at the entry gate 
to the port for instance by tripping a switch- that may 
cause the vehicle identity to be read. The reading of a 
vehicle identity may also occur by sensors located at the 
vehicle parking spaces, or at the entrance to the parking 
tot. In addition placing a vehicle in park in a parking 
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space and opening the door may signal the end of the 
trip, or a user may directly enter that the trip is over on 
the vehicle console. There is a great variety of flexibility 
in methods of deciding that a vehicle is in the parking 
state and the exact method chosen will depend on the 
implementation. 

[0086] In yet further embodiments of the invention in 
which vehicles in the fleet include electric powered ve- 
hicles, the vehicle subsystem for each electric powered 
vehicle includes a state of charge SOC monitor 204 for 
monitoring the available charge remaining in the vehi- 
cle. Data representing the SOC is provided to the proc- 
essor 188, for transmission to the central station 12 by 
the transmitter/receiver 190 for use vehicle allocation 
and monitoring functions described above. Data repre- 
senting other parameters 207, such as vehicle speed, 
door open, vehicle charging, and so forth are also pro- 
vided to the processor 1 88, for transmission to the cen- 
tral station 1 2 by the transmitter/receiver 1 90. 
[0087] In yet further embodiments, the vehicle sub- 
system includes a vehicle location or tracking system. 
Such systems are known in the art. Vehicle location may 
be tracked through a variety of methods, the vehicle it- 
self can employ triangulation using radio beacons or 
dead reckoning, the vehicle may also be tracked by re- 
ceiving a signal from the vehicle and triangulating on 
that signal. In one further embodiment a GPS device 
206 provides location information to the processor 188, 
for transmission to the central station 1 2 and/or for pro- 
viding on-board tracking and route planning data. The 
choice of tracking system, however is a matter of imple- 
mentation convenience. 

[0088] The foregoing description of the preferred em- 
bodiment of the invention has been presented for the 
purposes of illustration and description. It is not intended 
to be exhaustive or to limit the invention to the precise 
form disclosed. Many modifications and variations are 
possible in light of the above teaching. For example, 
while many of the data processing and decision making 
functions are described above as being performed by 
the central facility, other embodiments may include port 
facility computer substystems that are programmed to 
perform some of such functions. In yet further embodi- 
ments, the vehicle susbsystem may be programmed to 
perform some of such functions. Therefore, it is intended 
that the scope of the invention be limited not by this de- 
tailed description, but rather by the claims appended 
hereto. 



Claims 

1. A vehicle sharing system for sharing one or more 
vehicles from a fleet of vehicles among one or more 
users, the vehicle allocation system comprising: 

one or more ports at geographically remote lo- 
cations relative to each other, each port having 



a user interface terminal for receiving a request 
for a vehicle from the fleet; 
a computer system coupled for communication 
with the user interface terminal at each port and 

5 programmed for processing a user request re- 

ceived at a port and, in response thereto, for 
determining a group of vehicles from the fleet 
which are available to the user at that port, said 
group may include less than all of the vehicles 

io in the fleet; and 

means for detecting a parking state of a vehicle 
from the fleet and, in response thereto, includ- 
ing the vehicle in the group of available vehicles 
of one of said ports. 

15 

i 

2. A system as recited in claim 1 , wherein said means 
for detecting the parking state of a vehicle compris- 
es a sensor for sensing the setting of the vehicle in 
a parking gear. 

20 

3. A system as recited in claim 1 , wherein said means 
for detecting the parking state of the vehicle com- 
prises a sensor for sensing the opening and/or clos- 
ing of a door of the vehicle. 

25 

4. A system as recited in claim 1 , wherein: 

said computer system includes means for de- 
tecting the location of each vehicle in the fleet; 
30 and 

said means for detecting the parking state of 
each vehicle comprises means for determining 
whether the detected location of each vehicle 
is within a designated area. 

35 

5. A system as recited in claim 1 , wherein: 

each port includes a parking facility in which 
one or more vehicles may be parked at any giv- 
40 en time; 

said computer system includes means for de- 
tecting the location of each vehicle in the fleet; 
and 

said means for detecting the parking state of 
45 each vehicle comprises means for determining 

whether the detected location of each vehicle 
is within the parking facility of one of said ports. 

6. A system as recited in claim 5, wherein a vehicle 
so detected in a parking state of the parking facility of 

a port is included in the group of available vehicles 
of that port. 

7. A system as recited in claim 1, wherein: „ 

55 

said computer system includes means for de- 
tecting the location of each vehicle in the fleet; 
and 
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said means for detecting the parking state of 
each vehicle comprises a sensor for sensing 
the setting of the associated vehicle in a park- 
ing gear and means for determining whether 
the detected location of each vehicle is within s. 
a designated area and detects a parking state 
of a given vehicle upon the occurrence of both 
the vehicle being within the designated area 
and the vehicle being set in a parking gear. 

10 

8. A system as recited in claim 1 , wherein: 

each port includes a parking facility in which 
one or more vehicles may be parked at any giv- 
en time; 75 
said computer system includes means for de- 
tecting the location of each. vehicle in the fleet; 
and 

said means for detecting the parking state of 
each vehicle comprises a sensor for sensing 20 
the setting of the associated vehicle in a park- 
ing gear and means for determining whether 
the detected location of each vehicle is within 
a parking facility of a port and detects a parking 
state of a given vehicle upon the occurrence of 25 
both the vehicle being within the parking facility 
of a port and the vehicle being set in a parking 
gear. 

9. A system as recited in claim 1 , wherein: 3° 

said computer system includes means for de- 
tecting trie location of each vehicle in the fleet; 
and 

said means for detecting the parking state of a 35 
given vehicle comprises a sensor for sensing 
the opening and/or closing of a door of the ve- 
hicle and means for determining whether the ■-: 
detected location of the vehicle is within a des- 
ignated area and detects a parking state of the *o 
given vehicle upon the occurrence of both the 
vehicle being within the designated area and 
the vehicle door opening and/or closing. 

10. A system as recited in claim 1 , wherein: 45 

each port includes a parking facility in which 
one or more vehicles may be parked at any giv- 
en time; 

said computer system includes means for de- 50 
tecting the location of each vehicle in the fleet; 
and 

said means for detecting the parking state of a 
given vehicle comprises a sensor for sensing 
the opening and/or closing of a door of the ve- & 
hide and means for determining whether the 
detected location of the vehicle is within a park- 
ing facility of a port and detects a parking state 



of the given vehicle upon the occurrence of both 
the vehicle being within the parking facility of a 
port and the vehicle door opening and/or clos- 
ing. 

11. A system as recited in claim 1, wherein said com- 
puter system is further programmed to select and 
allocate one of the vehicles from the group of avail- 
able vehicles, in response toa request for a vehicle. 

12. A system as recited in claim 11 , wherein said com- 
puter system is further programmed to remove a ve- 
hicle from the group of available vehicles at a port, 
upon allocation of the vehicle, in response to a re- 
quest. 

13. A system as recited in claim 12, wherein said com- 
puter system is further programmed to return an al- 
located vehicle to the group of available vehicles at 
a port upon return of the vehicle to the port and plac- 
ing of the vehicle in a parking state. 

14. A system as recited in claim 12, wherein said com- 
puter system is further programmed to return an al- 
located vehicle to the group of available vehicles at 
a port, upon failure of the user to confirm receipt of 
the vehicle within a preset time from the allocation 
of the vehicle. 

15. A method for sharing one or more vehicles from a 
fleet of vehicles among one or more users, the 
method comprising: 

providing a user interface at one or more ports 
at geographically remote locations relative to 
each other, 

receiving a request for a vehicle from the fleet 
on a user interface terminal at one of said ports; 
determining, in response to a user request, a 
group of vehicles from the fleet which are avail- 
able to the user at that port, said group may in- 
clude less than all of the vehicles in the fleet; 
and 

detecting a parking state of a vehicle from the 
fleet and, in response thereto, including the ve- 
hicle in the group of available vehicles of one 
of said ports. 

16. A method as recited in claim 15, wherein said step 
of detecting the parking state of a vehicle comprises 
sensing the setting of the vehicle in a parking gear. 

17. A method as recited in claim 15, wherein said step 
of detecting the parking state of the vehicle com- 
prises sensing the opening and/or closing of a door 
of the vehicle. 

18. A method as recited in claim 15, further comprising 
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the step of detecting the location of each vehicle in 
the fleet, and wherein said step of detecting the 
parking state of each vehicle comprises determin- 
ing whether the detected location of each vehicle is 
within a designated area. 5 

19. A method as recited in claim 1 5, further comprising 
the step of detecting the location of each vehicle in 
the fleet, and wherein said step of detecting the 
parking state of each vehicle comprises determin- 10 
ing whether the detected location of each vehicle is 
within a parking facility of one of said ports. 

20. A method as recited in claim 19, wherein a vehicle 
detected in a parking state of the parking facility of .is 
a port is included in the group of available vehicles 

of that port. 

21. A method as recited in claim 15, further including 
the step of detecting the location of each vehicle in 
the fleet, and wherein the step of detecting the park- 
ing state of each vehicle comprises sensing the set- 
ting of the associated vehicle in a parking gear and 
determining whether the detected location of each 
vehicle is within a designated area, wherein a park- 
ing state of a given vehicle is detected upon the oc- 
currence of both the vehicle being within the desig- 
nated area and the vehicle being set in a parking 
gear. 

22. A method as recited in claim 1 5, further comprising 
the step of selecting one of the vehicles from the 
group of available vehicles, in response to a request 
for a vehicle. 

23. A method as recited in claim 22, further comprising 
the step of removing a vehicle from the group of 
available vehicles at a port, upon allocation of the 
vehicle, in response to a request. 

24. A method as recited in claim 23, further comprising 
the step of returning an allocated vehicle to the 
group of available vehicles at a port upon return of 
the vehicle to the port and placing of the vehicle in 
a parking state. 

25. A system as recited in claim 23, further comprising 
the step of returning an allocated vehicle to the 
group of available vehicles at a port, upon failure of 

the user to confirm receipt of the vehicle within a so 
preset time from the allocation of the vehicle. 
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and location 
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user declines 
vehicle 
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system sends 

user ID 
information 
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user walks up 
to vehicle 
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user decides 

to wait 
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not to wait 
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user waits 
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arrives 
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if no 
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if yes 
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vehicle access now chart 
continued from registration How chart 
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user must swipe card at a vehicle 
within 5 min of accepting vehicle 
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user swipes card 
I 
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user ID disabled 
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match 
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and closes door 
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user enters 
correct PIN 
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user leaves 
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vehicle trip flow chart 
continued from system and user flow chart 
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user shifts into drive 
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and usage time 
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displays usage time 



user stops 
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user puts vehicle 
into park 

I 



ignition access 
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shut, doors lock 
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system returns 
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system is idling 



swipe card 



access to registration 
web-server 



send kiosk ID & user ID 



web server compares user ID 
against active user list 



kiosk-data process 
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user ID is valid 
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user ID is 
invalid 



web-server collects 
user request information 



kiosk-data process 
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destination 
estimate time 
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active 



server return 
screen page 
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admin process 
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vehicle location & status 



web-server 
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kiosk-data process 
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user accepts 



web-server adds use request 
to shared database 
containing the pertinent 
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user declines 
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web-server 
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